私流・データ分析基盤の技術調査のコツを整理してみた
データアナリティクス事業本部の鈴木です。
自分がデータ分析基盤の技術調査をする際、こういうことに気をつけるとうまく行きやすいなというポイントがまとまってきたので、ブログにしてみました。
あくまで1例として参考になればと考えています。
課題意識
ほかのメンバーで、技術調査に慣れていない方に調査をお願いするとき、初めはある程度やり方を説明したり、レビューを手厚くしたりすると思います。私が初めて技術調査をしたときは、やり方が分からず、先輩にかなりお世話になったことを覚えています。
最近では、私からほかのメンバーに調査をお願いをする側になる場面が少しづつ出てきたので、「お願いしたいことはある程度ブログにしておいた方が、聞く方が言われたことを全部覚えてなくていいし、絶対ええやろな〜」と思い、記事にしてみました。
場面としてはデータ分析基盤を構築する上で必要になる技術調査を想定しています。
技術調査の種類
データ分析基盤を構築する上で必要になる「技術調査」は、特に以下の3種類が多いと思うので分類してみました。
- 技術選定のための調査
- 設計段階で、なにをどんな風に組み合わせれば要件が実現できるか調べます。この記事では特にこの点を中心に記載します。
- 詳細な仕様確認のための調査（仕様が詳細に分かるもの）
- 詳細設計や実装段階で、必要な仕様を調べます。例えば、自分でツールなどを作成する際に、使用している言語や依存するツールの仕様が細かい粒度で分かったり、採用したツールがOSSでソーコードが読めたりするケースです。
- 選定した技術を実際に使って機能を実現する段階で行うことが多いと思います。
- 詳細な仕様確認のための調査（仕様が公開された情報に限られたもの）
- 詳細設計や実装段階で、必要な仕様を調べます。SaaSや詳細な実装が明らかにされていないクラウドサービス向けの調査です。
- 仕様がその製品のドキュメントなどの公開された場所で公開されていることが多いケースです。
技術選定のための調査のコツ
まず、技術選定のための調査についてです。技術調査をする場合はこの種類が多いと思うので、この種類を中心に説明します。
チェックポイントを意識する
ふつう１回のレビューで、調査の依頼側が納得する結果がまとめられることは少ないと思います。そのため、何回かレビューを設けて進めていく方が進めやすいです。
個人的には、以下のように調査開始日から予定終了日までを、お尻に数日バッファを残して以下のようにチェックポイント間の時間を1:1:2に分けるのがお勧めです。
各チェックポイントは以下のようなものです。
各チェックポイントの目的は以下になります。
| チェックポイント | 目的 | 備考 |
|---|---|---|
| 進捗確認 | 調査の大方針があっているか確認する。依頼側の意図と異なる調査を行い、手戻りが発生することを防ぐ。不要であればなくてもよい。 | 調査対象の大分類〜中分類が洗えているくらいで臨んでよい。できれば深掘りしたい推しの調査対象が決められていると、今後の進め方を相談しやすい。 |
| 中間レビュー | 調査実施側と依頼側の調査結果のイメージをすり合わせる。 | これがいいだろうと思っている候補については、ある程度深く調査できていて欲しい。ほかの候補については、洗い出しができている程度でも大丈夫。 |
| 最終レビュー | 調査結果を確認する。懸念事項があれば付け足しを依頼する。 | |
| 〜調査終了 | 最終レビューで指摘があったことを追加で調査し、結果に付け足す。 | 最終レビューにて依頼側が思った懸念事項や追加調査対象についてはここまでで結果を付け足す。 |
例えば現状のデータ分析基盤のデータ収集機能は、AWSやGoogleクラウドのようなパブリッククラウド上のオブジェクトストレージやDWH製品に、SaaSやOSSなどを使って作るようなケースが多いと思います。その場合、まずは要件に合わせてざっくり調べ、最初の進捗確認で方向性に問題がないか確認した後、重要なところから詳細に調査し、依頼側でさらに調べて欲しいところがないか確認しながら進めると手戻りが少ないように思います。
注力する観点と、しない観点を明らかにする
全部を同じパワーで調査すると時間がかかりすぎるため、筋がよさそうなものは優先して細かく調査し、そうでないものは項目の洗い出しくらいに一旦とどめ、依頼側の反応を見つつ調査が必要そうであれば後追いで調べるように調整すると進めやすいです。そのためにも、まずは候補を洗い出し、その後にどの候補を注力して調査するか考えます。注力するところとそうでないところは、進捗確認や中間レビューで求められることに合わせてすり合わせしていきます。
同じことですが、自分の中で推しの選択肢はどれか決めておくことも重要です。特に各チェックポイントで説明する際には、自分はどれが良いと思っているかの意見を添えることで、依頼側も「うーん、それを第一候補にするのは違うんじゃない？」や「そこがいいのは分かったけれど、こういう観点が抜けてるから追加調査して欲しいな」などと返事がしやすいです。
調査結果は網羅性に気をつけて整理する
調査対象を洗い出す際、いきなり手を着けるより一度大きい粒度からどう分類できるか考えると、網羅的に候補を出して調査の抜け漏れを減らしやすいです。一方で、詳しくない分野だといきなり網羅的に書き出すことは難しいかも知れないので、その場合は分かるものから調べつつ、ほかにどんな選択肢があるのか探るのも進めやすいです。この場合、最終的には網羅的に整理することが必要なのは忘れないようにしましょう。
結果は最初は表形式に整理するとよいでしょう。整理するときは、左側から右に行くほど、粒度が細かくなるように整理します。理由は、「チェックポイントを意識する」と「注力する観点と、しない観点を明らかにする」を踏まえると項目によって調査具合に違いがあるので、どれが頑張って調べたもので、どれがそうでないのか分かるようにするためです。もちろん必ずしも表である必要はなく、自分とレビュー側がお互い把握しやすい方法で構いませんが、その場合も網羅的に候補を考えられていることがポイントになります。
表のまとめ方の考え方は以下の記事を参照ください。
上記のポイントを踏まえて、表の例を作ってみました。
要件は以下のようなものを想定しました。
- サーバーにAWSへアプリケーションログを配信する。
- ログの連携は日時バッチでもよいが、可能であればそれよりも早くみられるようにしたい。
- ログは一定期間クラウド上に保存したい。
- 将来分析に使うかもしれないが、いまは検索ができればよい。
大方針ではサーバーからAWSに送り、その中でも一旦CloudWatch Logsにデータを格納しておくのが良いだろうという見立てなので、No.1~3の項目を特に手厚く記載しています。逆にNo.5の案はレビューを進める中で依頼側が関心があれば調査をすればよいだろうという想定で、一旦案を挙げるにとどめています。
詳細な仕様確認のための調査のコツ
基本的には技術選定のときと同じですが、特筆したい点を記載します。
仕様が詳細に分かるもの
選定した技術を実際に使って機能を実現するための調査です。実際に動かしてみたり、ドキュメントの該当する箇所を詳細に読み込んだりして、理解を進めるとよいです。
また、時間や必要性があればソースコードを読んだりもします。例えばembulkはソースコード自体がGithubに公開されていますし、ホームページに公開されている各種プラグインも同じく公開されています。細かい動きを知りたい場合は、実装内容を読むことまで可能です。
仕様が公開された情報に限られたもの
技術選定でSaaSやクラウドサービスを選定したけれど、後から要件が増えたような場合、やりたいことを実現するための仕様が存在するのか追加で調べる必要があります。
まずはドキュメントに該当の仕様が書いてあるか確認します。もし記載があれば、実際に動かしてみて動作を確認し、分かったことを報告します。
ドキュメントに書いていない場合は、社内に知っている人がいないか聞いてみたり、インターネットで同様の問題に当たっている人がいないか調べたりします。探してもその情報がないこともあり、時間を溶かしてしまうことがあります。そうなりそうな場合は、製品の技術サポートに問い合わせする方法があると思うので、事前にその方法を把握しておき、必要に応じて問い合わせすることを考えます。特に調査は時間を決めて行い、時間内にどうしても分からない場合は技術サポートに問い合わせできないか、チームメンバーや依頼側に相談してみましょう。
最後に
今回は、私のデータ分析基盤の技術調査のコツについてご紹介しました。誰でもこの方法でうまく行くとは限りませんが、1例として参考になれば幸いです。
